Developer CD Series 1997 January: Mac OS SDK/Dev.CD Jan 97 SDK2.toast/Development Kits (Disc 2)/OpenDoc/Developer Documentation/Human Interface/Human Interface Q & A/HI Q&A #1

Text File | 1996-04-26 | 14.1 KB | 264 lines | [ttro/ttxt]

Q & A #1

By the Apple Computer OpenDoc Human Interface Team

As published in the January 1995 Apple Directions .

We frequently receive questions about OpenDoc that need to be answered in a
public forum to help our partners' OpenDoc development efforts. These
questions come from our colleagues and engineers in the human interface
community through conversation and e-mail, and they address OpenDoc topics
we think more of you want to know about. The answers we provide are
applicable to all known implementations of OpenDoc. Platform specific
answers may be called out (with a link from here).

Q: What has changed from today's application-centered world?

A: A fundamental change from today's application-centered world is that
applications will be replaced with part editors and part viewers. In OpenDoc
the primary focus is on the user's tasks and data instead of on the part
editors being used. Editors are installed in a special folder, the Editors
folder, as described in the OpenDoc human interface guidelines. So the part
editors remain hidden until the user needs them to manipulate some content.
Today, when a user opens a document, its application generally starts
automatically. In OpenDoc, part editors start in a similar way. But OpenDoc
automatically stops part editors when they are no longer needed--that is,
when there are no longer any open documents that use them. This means that
the user never needs to quit, and a part editor never leaves its menu bar
displayed after its last window is closed. We think this minimizes user
confusion.

It's important to note, however, that because part editors are started and
stopped at random times, your part editor will cause distraction if it
displays a "splash screen" every time it is launched.

Macintosh Developers can check the OpenDoc Human Interface Guidelines for
the Macintosh on the OpenDoc with SOM Developer Release CD (sent to all
Apple Associates and Partners along with the January 1995 issue of Apple
Directions . This CD is also available in the January issue of MacTech
magazine.

Q: Is everything a document? What isn't?

A: Evidently, there is some real confusion over what a document is, and more
fundamentally, why this new technology is called OpenDoc. So what's in a
name? We currently think in terms of a document as the product of an
application--or the realization of a collection of ideas. We've taken that
concept a step further in OpenDoc and conceptualized the document as a
collection, not of static representations of ideas, but of active, live
parts. Consequently, an OpenDoc document is a bounding mechanism for just
about anything you'd like to collect together. In short, a document is a
container that is open to any kind of data or active behavior you want to
include.

For more info, you may find Gregg William's Strategy Mosaic column in the
November 1994 edition of Apple Directions, interesting. (Sorry, this isn't
online yet.)

Q: What is an active part?

A: This topic is often confusing the first time it's explained. Fortunately,
our user studies show that determining which part is active is transparent
to users--they don't have problems using this element of OpenDoc. (Hey,
maybe it's just that we didn't try to explain it to them.) But it is
important for developers to understand the conceptual model we are
presenting to our users. The active part is the part that is currently
receiving input events; it identifies itself by sporting the active border.
As a user "mouses around" and changes the selection or adds content, the
active border appears wherever there is a selection or insertion point in a
part. As in today's Macintosh environment, there is only one selection in a
window, so only one part is active at a time. When a part is active, its
menus are displayed in the menu bar, and it receives the keyboard and other
input device events. (Exception: When a dialog box is displayed by the
active part, it normally handles these events.)

You can think of the active part as being like the active window, which
indicates where the user is currently working. Today's active window uses
distinct visual feedback; similarly, the OpenDoc active part uses its own
visual feedback--the active border. This border is the boundary of the part,
and it tells users about the part in which they're working: how big an area
they have to work in, and how far they can drag and drop content before
going outside this part.

Let's assume that we're writing this article using an OpenDoc text editor,
instead of a conventional word processor. We're working inside the text part
and the text part is active. While using the text editor, we see the text
editor's menus. Now suppose we paste a picture into this text; that would be
a different part, but it would be content within the text. To edit the
picture, we just click inside the picture, and, because it now receives the
input focus, it becomes the active part, and the active border is drawn
around the picture instead of the text. Now the keyboard and other input
device events are being handled by the picture's part editor.

Q: Why not just click anywhere on a part to select it?

A: In an "inside-out" model, the first click performs an action on the
deepest level. The alternative "outside-in" model requires users to click
once to activate the content, and then again to set an insertion point or
make a selection. We know from research going back to the Xerox Star in the
early 1980s (and confirmed by our recent user studies) that users strongly
prefer to click once in some content to start editing it. We also know that
users edit the contents of a part more frequently than they manipulate an
entire part. Although these results are task-dependent and there isn't a
large percentage of difference in preferences, we believe we've learned that
the "inside-out" model of single-clicking to start editing improves the
usability of the system. Let's investigate the vagaries of single-clicking
and the reasons why OpenDoc uses it according to the "inside-out" model just
described. Imagine a different model in which the user single-clicks to
select the part. Once the part has been selected with a single click, this
model requires a different mechanism for editing the contents of the part.
But a part may contain more content nested within itself, and often the
nesting is invisible. Consequently, a model that uses a single click for
part selection demands that the user navigate an often invisible hierarchy.
The navigation mechanism typically used is the double click, because it
means "open." But it also means "select a word or some larger content."
Thus, when users try to insert a word into a label within a chart, they
might be forced to double-click several times to tunnel down through the
hierarchy of nested parts. And then at the end, if they misjudge the number
of levels, they are likely to inadvertently select a word instead of placing
an insertion point. With the OpenDoc model, a single click places the
insertion point where the user wants it.

Q: How do users make the transition from applications to parts? How

transparent is this transition? How can users tell if something is
"OpenDoc-enabled"?

A: From our user studies we kept hearing things like "You fixed some of the
bugs" and "That's the way it's supposed to work." We're very happy, because
we know it is vital that users feel that the system has improved, rather
than having simply changed. While we anticipate that users will notice that
working with parts is different from working with today's applications,
we've implemented sufficient visual feedback to let users know they're
working within OpenDoc. What, exactly, looks different about OpenDoc?
Working in OpenDoc doesn't necessarily look different from working in
today's environment. While users may use OpenDoc to create the same
traditional types of documents that they create today, they may also create
component documents that look and behave differently. It is the change in
how one interacts with a document that is significant, and we've developed
feedback such as active and selected part borders to help users shift focus
easily among various parts in a component document.

Additionally, OpenDoc has distinctive icons identified with the OpenDoc
logo. Since stationery and documents behave pretty much the same way they
always have, their icons should follow current icon development guidelines.
However, editor and viewer icons do not behave exactly like today's
application icons--for example, they won't perform correctly if they're not
properly stored, and double-clicking them doesn't produce the same results
as double-clicking an application icon. Therefore, we've developed a
distinctive shape for OpenDoc editor and viewer icons to help users notice
the difference.

To smooth the transition from applications to OpenDoc parts, we have
introduced guidelines on how to help your application fit in better in the
OpenDoc Human Interface Guidelines for the Macintosh on the OpenDoc with SOM
Developer Release CD. For example, supporting drag-and-drop capability is
highly encouraged.

Q: What is the role of stationery in OpenDoc? How should developers use
stationery?

A: OpenDoc uses stationery as a starting point for users to get a new
document or new kind of content into their document. Many applications today
ship stationery pads, and OpenDoc continues that practice. Most users will
start off using stationery supplied by part developers or by vertical market
developers, so shipping some samples is a good idea. You should ship at
least one stationery pad that can be used to create a new document
containing one instance of your part. As users become more sophisticated in
their use of stationery, they will develop their own novel forms and uses.

For example, if you ship a drawing editor, your stationery pad should create
an empty drawing document. If your editor does network database queries,
your stationery pad should create a document that contains a blank query
form. Of course, we encourage you to ship samples as stationery, too. For an
editor that does network database queries, you might provide two stationery
pads--one with a simple query and another with a more complex query.

Because stationery should be installed in a location that users can find
easily, we are introducing the Stationery Folder. Check the OpenDoc
Human Interface Guidelines for the Macintosh for details.

Q: What happens when I receive a document that uses an editor I don't have?


A: This is probably the question we're asked most frequently. The short
answer is that while there is no magic that can make the "missing editor"
problem disappear, there are at least two workable solutions: viewers and
translators. If users don't have the appropriate part editor (or
application), they pray that they have a useful viewer so that they can at
least view, if not manipulate, the document just received. Viewers currently
exist, and we suspect that needing to use one in the OpenDoc world should
occur about as often as it does now. We encourage developers to provide
translation as another option for working with data for which users have no
part editor. However, translation offers varying degrees of fidelity to the
original. The longer answer is that in today's offices and homes, users who
frequently exchange data tend to take advantage of the same set of
applications. This occurs because the use of common applications is mandated
by management, or is tacitly agreed upon among users. Users also tend to
have a few applications outside the set they commonly use so that they can
read documents sent from outside their immediate group.

All of these same solutions and more are used in OpenDoc. First, a part may
store its data in several formats so that quality translation is more
probable, if it should be required. Second, Apple strongly encourages you to
create a viewer for your part that can be distributed freely. That way,
OpenDoc will provide users with a better solution than today's applications,
because users will always be able to view a document, even when they don't
have the appropriate part editor to manipulate it.

Q: What is linking? For what is it intended?

A: Linking is intended to allow users to replicate data dynamically, much as
the publish and subscribe feature does in System 7.0. We know that the
publish and subscribe feature is not used by a large number of users. In
part, this is because many users don't need this functionality; it's also
because publish and subscribe is difficult to use. While OpenDoc's linking
has a much-improved interface, not every user will take advantage of
linking. Linking allows users to copy and paste data as a link from one
location to another, keeping the copy updated as the original changes. The
destination part accepts the link content as either merged or embedded
content. Links are one-way; that is, the original source content is
duplicated at the link destination. If the link destinations are within the
same document as the source, changes made at the source are automatically
and immediately reflected in the copied content at the link destination.
Links that cross document boundaries are automatically updated when the
document is saved, or the user can manually specify when to update.

Linking is an efficient way to keep copies of changing data in
synchronization when it is copied to many locations inside or outside the
original data's location. However, linking is also a way to use the same
data more than once, and display it differently (this is in addition to
OpenDoc's ability to display a part in several alternate "views"). Linking
allows multiple copies of the part to stay synchronized. Thus, for example,
a spreadsheet can be duplicated so that the original (or source) data is
displayed as a spreadsheet, and the other copy (the destination) is
displayed as a bar chart; the bar chart changes its display whenever the
spreadsheet changes.

We use special link borders to indicate to the user that some content is a
link. Consult the OpenDoc Human Interface Guidelines for the Macintosh for
more details on the behavior and the display guidelines for linking.

_______________________________________________________
Authors: Dave Curbow and Elizabeth Dykstra-Erickson writing for the OpenDoc
Human Interface teams.

Copyright (c) 1995 by Apple Computer, Inc. All Rights Reserved.